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ABSTRACT 



An apparatus and concomitant method for generating an 
OSD message by constructing an OSD bitstream defining a 
single field of OSD data. The OSD bitstream contains an 
OSD header and OSD data. An OSD unit retrieves pixel 
control information from the OSD header which is pro- 
grammed by a processor of a decoding/displaying system. 
The OSD header contains information including various 
pointers, that are used to provide instructions as to the 
treatment of the OSD data. If a top field pointer and a bottom 
field pointer are set to an identical value in the OSD header, 
then the OSD unit will repeat each OSD line in the other 
field for an OSD region. 

10 Claims, 4 Drawing Sheets 
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APPARATUS AND METHOD FOR 
GENERATING ON-SCREEN-DISPLAY 
MESSAGES USING FIELD DOUBLING 



FIELD OF THE INVENTION 

The present invention relates to a method and apparatus 
for generating On-Screen -Display (OSD) messages using a 
field doubling mode. More particularly, this invention relates 
to a method and apparatus that reduces the memory band- 
width requirements of a decoding/displaying system by 
repeating a lop field of OSD data in the bottom field for an 
OSD region. 

BACKGROUND OF THE INVENTION 

On-Screen-Display messages play an important role in 
consumer electronics products by providing users with inter- 
active information such as menus to guide them through the 
usage and configuration of the product. Other important 
features of OSD include the ability to provide Closed 
Captioning and the display of channel logos. 

However, the heightened standard of digital video tech- 
nology presents an ever increasing problem of generating 
and displaying OSD messages. For example, there are 
specific High Definition Television (HDTV) requirements 
that an HDTV must display up to 216 characters in four (4) 
"windows" versus the current National Television Systems 
Committee (NTSC) requirements of a maximum of 128 
characters in one "window". These new requirements place 
severe strains on the decoding/displaying system used to 
decode and display television signals (e.g., HDTV, NTSC, 
MPEG, and the like), which must decode the incoming 
encoded data streams and present the decoded data to a 
display system with minimal delays. Since OSD messages 
must be displayed (overlaid) with the video data, the micro- 
processor of the decoding/displaying system must assign a 
portion of the memory bandwidth to perform OSD 
functions, thereby increasing the memory bandwidth 
requirements of a decoding/displaying system and the over- 
all computational overhead. 

WO 90/15502 discloses a method and apparatus for 
superimposing information upon video signals and the like. 
Data which is to be combined with a composite video signal 
is stored in a replaceable memory device. A composite (e.g. 
television) signal is provided to an input. Horizontal and 
vertical sync signals are separated at a separator and then 
used to synchronize the reading functions from memory. In 
addition to display information, the data stored in memory 
includes frame count, line count and positional information 
by which initiation, line location and within-line position, 
respectively, of the display information are determined. The 
display information may include subliminal, supraliminal or 
both; and may be displayed repeatedly. A similar technique 
is employed to combine sound data with audio signals. 

Thus, a need exists for a method and apparatus for 
generating On-Screen-Display (OSD) messages without 
increasing the hardware requirements, e.g., memory 
bandwidth, of a decoding/displaying system. 

SUMMARY OF THE INVENTION 

The invention concerns an apparatus and concomitant 
method for generating OSD messages by constructing a 
valid OSD bitstream with instructions in the OSD header to 
repeal a top field of OSD data in the bottom field for an OSD 
region. 
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More specifically, in accordance with the invention, an 
OSD unit retrieves an OSD bitstream from a storage device. 
The OSD bitstream contains an OSD header and OSD data. 
The OSD header contains control information that is used to 

5 program a color palette of the OSD unit and to provide 
instructions as to the treatment of the OSD data. The control 
information is programmed by a processor of a decoding/ 
displaying system. 
The control information includes two OSD pixel data 

i° pointers, an "OSD Top Block Pointer" and an "OSD Bottom 
Block Pointer". These pointers (flags) inform the OSD unit 
where the top and bottom OSD pixel data are located 
respectively in the memory. By setting both pointers to the 
same value, the OSD unit repeats an OSD line of pixels in 

15 the other field. Namely, the top and bottom fields share the 
same OSD data. 

These and other aspects of the invention will be described 
with respect to the accompanying drawings. 

20 BRIEF DESCRIPTION OF THE DRAWING 

In the Drawings: 

FIG. 1 is a block diagram of a decoding/displaying system 
including an OSD unit in accordance with an aspect of the 
25 invention; 

FIG. 2 illustrates the structure of a sample OSD bitstream 
200 implementing Field Doubling; 

FIG. 3 is a block diagram which discloses the structure of 
a memory having various OSD headers and OSD top and 
30 bottom field bit maps (blocks) and their relationships to a 
displayed frame; and 

FIG. 4 is a flowchart illustrating the method for construct- 
ing a valid OSD bitstream implementing Field Doubling. 

35 DETAILED DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a block diagram of a decoding/ 
displaying system for television signals 100 (hereinafter 
decoding system). The decoding system comprises a pro- 

40 cessor 130, a random access memory (RAM) 140, a read- 
only memory (ROM) 142, an OSD unit 150, a video decoder 
160, and a mixer 170. The output of the mixer 170 is coupled 
to a display device 190 via path 180. 

The present invention is described below in accordance 

45 with the MPEG standards, ISO/IEC international Standards 
11172 (1991) (generally referred to as MPEG-1 format) and 
13818 (1995) (generally referred to as MPEG-2 format). 
However, those skilled in the art will realize that the present 
invention can be applied or adapted to other decoding 

50 systems implementing other encoding/decoding formats. 
In the preferred embodiment, the decoding system 100 
performs real time audio and video decompression of vari- 
ous data streams (bilstreams) 120. The bitstreams 120 may 
comprise audio and video elementary streams that are 

55 encoded in compliance with the MPEG-1 and MPEG-2 
standards. The encoded bitstreams 120 are generated by an 
encoder (not shown) and are transmitted to the decoding 
system through a communication channel. The encoded 
bitstreams contain a coded representation of a plurality of 

60 images and may include the audio information associated 
with those images, e.g., a multimedia data stream. The 
multimedia source may be a HDTV station, a video disk, a 
cable television station and the like. In turn, the decoding 
system 100 decodes the encoded bitstreams to produce a 

65 plurality of decoded images for presentation on the display 
190 in synchronization with the associated audio informa- 
tion. However, for the purpose of this invention, the audio 
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decoding function of the decoding system 100 is irrelevant More specifically, the processor 130 programs (formats 

and, therefore, not discussed. and stores) the OSD header io the memory 140. The OSD 

More specifically, processor 130 receives bitstreams 120 header contains information concerning the locations of the 

and bitstreams 110 as inputs. Bitstreams 110 may comprise top and bottom OSD field bit maps, palette data, pointer to 

various control signals or other data streams that are not 5 the next header block and various display modes involving 

included in the bitstreams 120. For example, a channel OSD resolution, color and compression. Once the OSD 

decoder or transport unit (not shown) can be deployed header is programmed, the processor 130 may manipulate 

between the transmission channel and the decoding system the OSD data in the memory 140 in accordance with a 

100 to effect the parsing and routing of data packets into data particular implementation. Alternatively, the processor may 

streams or control streams. 10 simply program the OSD header with pointers to the OSD 

In the preferred embodiment, processor 130 performs data in the memory, where the stored OSD data is retrieved 

various control functions, including but not limited to, without modification to form the OSD bitstream. A detailed 

providing control data to the video decoder 160 and OSD description of the various OSD pointers is discussed below 

unit 150, managing access to the memory and controlling the witn reference to FIG. 2. 

display of the decoded images. Although the present inven- 15 The processor 130 then reports the enable status, e.g., 

tion describes a single processor, those skilled in the art will OSD active, to the OSD unit 150, which responds by 

realize that the processor 130 may comprise various dedi- requesting the processor 130 for access to the OSD bitstream 

cated devices. to manage specific functions, e.g., a memory stored within the memory 140. The OSD bitstream is formed 

controller, a microprocessor interface unit and the like. and retrieved as the OSD unit 150 reads the OSD headers, 

Processor 130 receives bitstreams 120 and writes the data 20 each followed by its associated OSD data. After receiving 

packets into the memory 140 via video decoder 160. The the °SD bitstream, the OSD unit processes the OSD pixel 

bitstreams may optionally pass through a First-In-First-Out data in accordance with the instructions or selected modes in 

(FIFO) buffer (not shown) before being transferred via a the 0SD header. The OSD unit then waits for a pair of 

memory data bus to the memory. Furthermore, there is display counters (not shown) to attain count values that 

generally another memory (not shown) which is used solely 25 identifies the correct position on the display for inserting the 

by the processor 130. OSD information (messages). At the correct position, the 

Hie memory 140 is used to store a plurality of data 0SD unit forward s its output to the mixer 170. The output 
including compressed data, decoded images and the OSD bit of the 0SD umt 150 15 a slream or sequence of digital words 
map. As such, the memory is generally mapped into various , n re P resentin § respective luminance and chrominance compo- 
buffers, e.g., a bit buffer for storing compressed data, an nents of the on screen dls P lav - New memory accesses are 
OSD buffer for storing the OSD bit map, various frame requested as required to maintain the necessary data flow 
buffers for storing frames of images and a display buffer for ( 0SD bltstream ) throu g h the OSD unit to produce a corn- 
storing decoded images prehensive OSD display. When the last byte of the OSD 

In accordance with the MPEG standards, the video 35 pixel dat \ for the J ™ ° SD re ^ n * from lhe 

decoder 160 decodes the compressed data in the memory memor >;' the u next ° SD , ff ca * r . 15 ad , and P^ess is 

140 to reconstruct the encoded images in the memory. In repeated ^P*™* and ™ludmg the last OSD region for 

the current trsmc 

some cases, the decoded image is a difference signal that is 

added to a stored reference image to produce the actual 'Those skilled in the art will realize that the order of 

image in accordance with the compression technique used to 40 constructing and retrieving the OSD bitstream as discussed 

encode the image (e.g., to facilitate decoding a motion above can be modified. For example, the OSD header can be 

compensated image). Once an image is reconstructed, it is read from tne memorv as the processor is formatting the 

stored in the display buffer pending display via the mixer 0SD data > or tne 0SD data can be processed and displayed 

170. as OSD messages by the OSD unit without having to retrieve 

Similarly, the OSD unit 150 uses the memory 140 to store 45 the eDtire 0SD bitstrcam - 

the OSD bit map or the OSD specification. The OSD unit sincc OSD pixel data is superimposed on the decoded 

allows a user (manufacturer) to define a bit map for each image, the mixer 170 serves to selectively blend or multiplex 

field which can be superimposed on the decoded image. The the decoded image with the OSD pixel data. Namely, the 

OSD bit map may contain information which is stored in a mixer 170 has the capability to display at each pixel 

storage device, e.g., a ROM, concerning the configuration 50 location, an OSD pixel, a pixel of the decoded image or a 

and options of a particular consumer electronics product. combination (blended) of both types of pixels. This capa- 

Alteraatively, the OSD bit map may contain information bility permits the display of Closed Captioning (OSD pixel 

relating to Closed Captioning and channel logos that are data only) or the display of transparent channel logos (a 

transmitted from a cable television, a video disk and the like. combination of both OSD pixels and decoded image pixels) 

An OSD bit map is defined as a set of regions (generally in 55 on a decoded image. 

rectangular shapes) of programmable position and size, each Video decoder 160 and OSD unit 150 both form streams 

of which has a unique palette of available colors. or sequences of digital words representing respective lumi- 

The OSD bit map is written into the OSD buffer of the nance and chrominance components. These sequences of 

memory 140 which is assigned for this purpose by the user. video component representative digital words are coupled 

However, those skilled in the art will realize that a ROM 142 60 y i a mixer 170 to a digital-to-analog converter (DAC) 185. 

or other equivalent storage devices can also serve this The luminance and chrominance representative digital 

function as well. words are converted to analog luminance and chrominance 

When the OSD function is enabled for a particular image signals by the respective sections of the DAC. 

or frame, the processor 130 manipulates the data in memory The OSD unit 150 can be used to display a user defined 

140 to construct an OSD bitstream. The OSD bitstream 65 bit map over any part of the displayable screen, independent 

contains an OSD header and OSD data (data defining the of the size and location of the active video area. This bit map 

OSD pixels). can be defined independently for each field and specified as 
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a collection of OSD regions. A region is often a rectangular the bottom block pointer 242. This setting causes the OSD 

area specified by its boundary and by a bit map defining its unit ISO to interpret the locations of the OSD data for both 

contents. The bit map is displayed in a plurality of OSD the top and bottom fields to be located in the same memory 

lines, where each OSD line represents a line of OSD pixels location. This setting causes the OSD unit 150 to display the 

in an OSD region. Each region has associated with it a 5 samc OSD data for both top and bottom fields in an OSD 

palette defining a plurality of colors (e.g., 4 or 16 colors) region , ln essenc<!) , he 0SD unil repeats „ 0SD Hne of 

which can be used within that region. If required, one of pixe|s in , he other field (p iM Dou bling). As such, the 

these colors can be transparent, allowing the background to ssof 130 fa Qn , ired (0 , e 0Qe . half f , he 

show through as discussed above OSD data. Namely, the size of the OSD bitstream is reduced 

However, handling the OSD functions for a frame 1Q b y approximately 50%. 
increases the computational overhead of the processor 130 

and, more importantly, places severe strains on the memory The 0SD data 220 contains bit map data in left to right 

bandwidth of the processor because the processor 130 must and t0 P t0 bottom order. The OSD data is generally used to 

service memory requests from both the video decoder 160 define the color index to the OSD palette for each pixel in 

and the OSD unit 150. As such, the present invention tne bit map imagery. If Field Doubling is implemented for 

reduces the size of the OSD bitstream by implementing the 15 a " interlaced display, the OSD data 220 defines OSD data 

Field Doubling Mode. By repeating each OSD line for both for onl y a single field 230. Since the top and bottom block 

top and bottom fields, the amount of OSD data that must be pointers are set to the same value, the OSD unit 150 only 

stored and read from the memory 140 is reduced by 50%. needs to read a single field of OSD data versus two fields. 

FIG. 2 illustrates the structure of a sample OSD bitstream ^ decision as to which field (top or bottom) to repeat, is 

200 implementing "Field Doubling". The OSD bitstream 20 determined by the processor 130. Generally, the selection of 

comprises a plurality of OSD headers 210, each followed by onc field over another would not produce a noticeable 

OSD data 220. In one embodiment, the header is comprised difference. 

of five 64-bit words, followed by any number of 64-bit OSD FIG. 3 illustrates a block diagram which discloses the 

data (bit map) words. The OSD header 210 contains infor- structure of a memory 340 having various OSD headers and 

mation relating to the OSD region coordinates 214, the 25 OSD top and bottom field bit maps (blocks) 310-330 and 

various entries of the palette 216 for a particular OSD their relationships to a displayed frame 350 having a plu- 

region, and various function codes (bits) 212. Those skilled rality of OSD regions 352 and 354. To illustrate, for each 

in the art will realize that the OSD header can be of any "OSD active" frame, the OSD unit 150 requests memory 

length. A longer header can provide more information and accesses starting at the memory location pointed to by the 

options, e.g., a palette with more entries, but at the expense register 305. The OSD unit 150 reads the first OSD header 

of incurring a higher computational overhead, i.e., more read block 310 to determine where the top 312 and bottom 314 

and write cycles are required to implement' the OSD func- OSD field bit maps arc located for an OSD 1 region 352. 

tions. In fact, the content of the OSD header is illustrative of When the OSD data from both fields are read by the OSD 

a particular embodiment and is not limited to the specific unit, the OSD unit sends a new header address to the 

arrangement as illustrated in FIG. 2. 35 processor 130 using the "next header pointer" which is 

The palette 216 contains a plurality of entries where each stored in the first OSD header 310. This process continues 

entry contains a representation of chrominance and lumi- untl l tne last OSD region is processed and displayed for the 

nance levels for an OSD pixel. The palette information 216 current displayed frame. 

is used to program the OSD palette. 4Q FIG. 3 illustrates an OSD 2 region 354, where Field 

The function codes (bits) 212 contain information relating Doubling is implemented. The OSD unit 150 reads the 

to various modes, including but not limited to, display second OSD header block 320 to determine where the top 

options and OSD bitstream options. The selection of the 326 and bottom 324 OSD field bit maps are located for an 

function codes 212 is controlled by the processor 130. OSD 2 region 354. Since the top and bottom block pointers 

The OSD region coordinates 214 contain the positions of 45 are sel 10 tne same value, the OSD unit 150 only reads a 

the left and right edge of an OSD region, i.e., row start and single field (top field 326) of OSD data. The single field of 

stop positions and column start and stop positions. These OSD data is repeated for the OSD 2 region 354. The bottom 

coordinates defines the location where an OSD region will OSD field bit map 324 is neither used nor read from the 

appear on a displayed frame. memory. In fact, for certain type of OSD data, the processor 

However, a conventional television display employs an 50 130 mav not construct the bottom OSD field bit map 324 at 
interlaced display technique, a form of subsampling, where 

every other line of an image is initially displayed (scanned). This mode of operation allows the processor 130 to gain 

Once the initial scan is completed, a second scan of the a 2:1 compression ratio over the normal display mode where 

remaining set of lines is conducted starting from the top of the OSD bitstream carries both fields of OSD data. The 

the image. Namely, the odd numbered lines (generally 55 saving is more significant where the OSD regions are 

referred to as "top field" or "top block") of an image or particularly large. If Field Doubling is implemented, the 

frame is initially scanned, followed by a succeeding scan of OSD display resolution is vertically reduced by 50%, since 

the even numbered lines (generally referred to as "bottom each successive pair of horizontal OSD lines displays the 

field" or "bottom block") at a later time. For interlaced same information. 

display, the region coordinates 214 include the positions 60 However, a reduction in OSD resolution in exchange for 
(pointers) of the top 240 and bottom 242 field pixel bit maps a higher OSD message display rate is acceptable and appro- 
in the memory 140 for the corresponding OSD region. priate for various OSD implementations, e.g., Closed Cap- 
Finally, the OSD region coordinates 214 include a "next tioning. Closed Captioning requires the rapid display of 
header pointer" 244 for pointing to the next header block in OSD messages that generally correlate to words spoken for 
the memory 140. 65 a series of frames (images). Since it is desirable to view the ■ 
In the preferred embodiment, the processor 130 can Closed Captioning as the images are displayed, the reduc- 
selectively set the top block pointer 240 to the same value as tion in resolution is an acceptable tradeoff. Furthermore, 
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since the OSD messages within the Closed Captioning are 
displayed only briefly, the reduced resolution is generally 
not noticeable. Thus, the Field Doubling decreases the 
number of memory operations without limiting the display 
capabilities of a particular OSD implementation. 

Finally, although Field Doubling may be implemented for 
one OSD header 210, the OSD unit 150 supports multiple 
header blocks which can each have a different resolution 
mode. Thus, the OSD unit is able to display different types 
of resolution or formats on the same video screen. For 
example, different OSD regions can be displayed in different 
resolutions depending on the OSD data being displayed. 

The implementation of the Field Doubling is controlled 
by the user via the processor 130. This control can be 
implemented using software that detects the need to mini- 
mize memory access by the OSD unit 150. For example, the 
video decoder 160 may receive a series of complicated 
encoded frames that require additional memory access. To 
minimize memory access conflicts between the OSD unit 
and the video decoder, the processor can offset the increased 
demand of the video decoder by implementing Field Dou- 
bling in the OSD bitstream. 

Finally, an alternate embodiment of the present invention 
incorporates a single bit in the OSD header to indicate 
whether the "Field Doubling Mode" is enabled. When this 
dedicated bit is enabled, the OSD unit will repeat the OSD 
data such that each OSD line is repeated in the other field. 

FIG, 4 illustrates a method 400 for constructing an OSD 
bitstream for implementing Field Doubling. The method is 
generally recalled from a storage device, e.g., a memory, and 
executed by the processor 130. The OSD bitstream is 
generated by the processor 130 and is processed by the OSD 
unit 150. Method 400 constructs an OSD bitstream by 
generating an OSD header having a plurality of control 
information including various pointers, followed by a plu- 
rality of data bytes. 

Referring to FIG. 4, the method 400 begins at step 405 
and proceeds to step 410 where method 400 determines 
whether the Field Doubling is enabled for an OSD region. If 
the query is negatively answered, method 400 proceeds to 
step 415 where the OSD data bytes are generated using a 
non-field doubling format. Method 400 then proceeds to step 
440. 

If the query at step 410 is affirmatively answered, method 
400 proceeds to step 420 where the top and bottom field 
points are set to the same value in the OSD header. Since the 
top and bottom field (block) pointers are set to the same 
value, the OSD unit 150 will only need to read a single field 
of OSD data. 

In step 430, a single field of OSD data is disposed within 
the OSD data bytes. Namely, the OSD bitstream only carries 
OSD data for every other OSD line, where each OSD line 
comprises sufficient OSD pixels for the OSD unit 150 to 
display a single horizontal line in an OSD region. 

In step 440, method 400 determines whether there is 
another OSD header. A new OSD header may be required if 
the various modes represented by the function bits 212 are 
modified. Similarly, a new header is required for each new 
OSD region on a frame. If the query is negatively answered, 
method 400 proceeds to step 450 where method 400 ends. If 
the query is affirmatively answered, method 400 proceeds to 
step 410 where the steps of 410-430 are repeated for each 
additional OSD header. In this manner, the OSD bitstream 
may comprise both field doubling OSD data bytes and 
non-field doubling OSD data bytes. 

There has thus been shown and described a novel method 
and apparatus for constructing an OSD bitstream that imple- 
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ments field doubling by using a single OSD pixel field. 
Many changes, modifications, variations and other uses and 
applications of the subject invention will, however, become 
apparent to those skilled in the art after considering this 

5 specification and the accompanying drawings which dis- 
close the embodiments thereof. All such changes, 
modifications, variations and other uses and applications 
which do not depart from the scope of the invention are 
deemed to be covered by the invention, which is to be 

10 limited only by the claims which follow. 
What is claimed is: 

1. Method for constructing an On-Screen Display (OSD) 
bitstream having an OSD header and OSD data, said method 
comprising the steps of: 

setting a first field pointer and a second field pointer to an 

identical value in the OSD header; and 
generating the OSD data including a plurality of OSD 
data bytes that define an OSD for a single display field, 
wherein the identical value corresponds to pointer data 
for accessing the plurality of OSD data bytes that define 
the OSD for a single display field, whereby the OSD for 
a single display field is generated for first and second 
display fields associated with the first and second 
25 pointers, respectively. 

2. The method of claim 1, wherein said first field pointer 
is a top field pointer and said second field pointer is a bottom 
field pointer, 

3. An OSD bitstream stored in a storage medium com- 
30 prising: 

a header having a first field pointer and a second field 
pointer, wherein said field pointers are set to an iden- 
tical value; and 
a plurality of OSD data bytes defining an OSD for a single 
display field, wherein the identical value corresponds to 
pointer data for accessing the OSD data bytes defining 
the OSD for a single display field, whereby the OSD for 
a single display field is generated for first and second 
40 display field associated with the first and second 
pointers, respectively. 

4. The OSD bitstream of claim 3, wherein said first field 
pointer is a top field pointer and said second field pointer is 
a bottom field pointer. 

4S 5. Apparatus for generating an OSD bitstream having an 
OSD header and OSD data comprising: 
a storage medium for storing the OSD header and OSD 
data; and 

a processor coupled to said storage medium, for generat- 
50 ing the OSD bitstream in a field doubling mode by 
setting a first field pointer and a second field pointer in 
the OSD header to an identical value and, for generat- 
ing OSD data including a plurality of OSD data bytes 
that define an OSD for a single display field, and for 
55 storing the OSD header in the storage medium, and the 
OSD data in a location in the storage medium in 
accordance with the identical value, whereby the OSD 
data bytes defining the OSD for a single display field is 
accessed in response to the first and second field 
60 pointers. 

6. The apparatus of claim 5, wherein said storage medium 
is a read only memory (ROM). 

7. The apparatus of claim 5, wherein said storage medium 
is a random access memory (RAM). 

65 8. The apparatus of claim 5, wherein said first field pointer 
is a lop field pointer and said second Geld pointer is a bottom 
field pointer. 
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9. Apparatus for generating an OSD message comprising: 

a storage medium for storing an OSD bitstream having a 
header and OSD data; 

a processor, coupled to said storage medium, for gener- 
ating the OSD bitstream in a field doubling mode by 5 
setting a first field pointer and a second field pointer to 
an identical value within said OSD header and, for 
generating OSD data including a plurality of OSD data 
bytes that define an OSD for a single display field, and 
for storing the OSD header in the storage medium, and 10 
the OSD data in a location in the storage medium in 
accordance with the identical value; and 

an OSD unit, coupled to the processor and the storage 
medium, for processing said OSD bitstream to form the 
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OSD message, wherein the OSD unit retrieves the OSD 
data bytes for the OSD for a single display field from 
the location in the storage medium in response to the 
first and second field pointers in the OSD header, 
whereby the OSD for a single display field is generated 
for first and second display fields associated with first 
and second field pointers, respectively. 

10. The apparatus of claim 9, wherein said first field 
pointer is a top field pointer and said second field pointer is 
a bottom field pointer. 
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